There are two types of memory pressure to consider - first, a system with too little physical RAM installed.  When a system has too little RAM, the Virtual Memory Manager has an increased workload as it attempts to keep the most recently accessed virtual memory pages of processes in Physical RAM so that they can be quickly retrieved.  Performance of both applications, and the overall system may suffer as a result of the increased paging to disk.  Although the excessive paging is really a secondary symptom, it is the easiest symptom to detect.  The second type of memory issue occurs when a process exhausts the available virtual memory.  This is most commonly referred to as a memory leak.  Most memory leaks are fairly easy to detect and are usually caused by software code defects.  However, normal system workload can also cause a memory depletion - there is no real memory leak, however overall virtual memory usage continues to grow until the system experiences a shortage.

One of the problems with configuring and troubleshooting memory on a system is that the memory is not used in quite the same fashion as the other hardware on a system.  Program instructions and data occupy physical memory to execute.  Often, they will occupy physical memory locations long after they are actively addressed.  The idle code and data are removed from RAM only when new requests for physical memory addresses cannot be satisfied from existing free RAM.  Also, because of the manner in which virtual memory address space is mapped to physical memory on demand, RAM tends to appear fully utilized all the time.

So now that we understand some of the mechanisms and how issues may manifest, how do we go about troubleshooting?  The first thing to understand is whether the problem is due to insufficient physical memory that results in excessive paging.  However, remember that excessive paging may occur even if there is plenty of available memory - for example if an application is leaking memory.  As we've mentioned before, it is important to have a baseline of your system's performance to compare to any new performance data that you gather.  Below are some of the key performance counters - the descriptions are pulled directly from the counter descriptions in Performance Monitor on Windows Vista:

So, if the page file shows a high degree of usage, the paging file may be sized too small.  Similarly, if the disk hosting the page file is excessively busy, overall system performance may be impacted.  Memory leaks caused by applications manifest in different ways - you may get an error message indicating that the system is low on virtual memory.  A memory leak in an application will show up as a gradual increase in the value of the Private Bytes counter listed above.  A memory leak in one process may cause excessive paging as it squeezes other process working sets out of RAM.

Now that you've gathered your data and determined what the issue is, how do you address it?  In the case of a server that is short on physical memory, you can either add more RAM (if the system hardware and the OS Version that you are running will support additional RAM).  You may also elect to offload some of the workload to another system.  However, if your data does not indicate an issue with the amount of Physical RAM, then it's time to look at other components that may be experiencing issues based on the data you have collected.

If the memory does seem to be an issue, then we have to determine the specific cause.  In Terminal Services environments in particular, as more and more applications are added to the Terminal Server environment, the amount of resources required by the various processes increases.  In some cases, you may be able to narrow down the cause to a specific process.  In those situations, one of two things may need to occur - you need to add more RAM to the machine, or there is a problem with the process itself that needs attention.  The key here is to understand exactly what the process is doing.  If the virtual memory of the process climbs steadily and then levels off, then increasing the size of the page file may be all that is needed to offer relief.  If there is still insufficient RAM however, you will notice increased paging which may result in system performance issues.  However, the key here is that the process does not consume virtual memory indefinitely - it levels off at a certain point.

On the other hand, if the application consumes memory and never levels off, then the application is probably leaking memory.  In a memory leak scenario, the application reserves and consumes memory resources, but never releases them when they are no longer required.  Depending on how severe the leak is, the virtual memory could be depleted within weeks, days, hours - or even minutes (in the most extreme circumstances)!  It is more normal to see a slow leak, which can be identified using Performance Monitor logging.

Another scenario that can cause performance degradation occurs when the page file itself is heavily fragmented.  This occurs when the page file is located on a disk that is heavily used by other applications.  In these cases, the disk itself is probably fragmented as well.  Defragmenting the disk should alleviate some of the issues, however since the built-in disk defragmenter does not defragment paging files, you may want to consider moving the page file to another drive temporarily, setting the page file on the fragmented disk to 0 MB.  Reboot the system to enable the other page file to be used and perform the disk defragmentation on the original drive.  Once the defragmentation is complete, you can reset the page file on the original drive to the necessary values, zero out the page file size on the temporary drive and reboot the system again.

That brings us to the end of this post.  In our next post, we'll continue our look at memory troubleshooting.  Until next time ...

Additional Resources:

- CC Hameed